The present embodiments are directed to a tool that allows users to selectively activate or implement computer application functions provided in an enhancement package into a computer application. In particular, the disclosed embodiments provide a tool that facilitates a more efficient selection of computer application functions that will be applied to the application as part of an enhancement package add-on.
Enhancement packages are used to provide updated computer application functionality and features to a user of a particular computer application, such as an enterprise resource management system or customer relationship management system. The enhancement package is structured such that a user can select which parts of the enhancement package that the user wants to install, or use after installation has occurred. As a result, both the installation of the enhancement package and the roll out of all of the updated computer application functions to the users do not have to occur substantially simultaneously. Using current systems, a user can choose when to roll out a particular computer application function. For example, in an enhancement package that is used by a number of departments within an entity, a human resources department of the entity may activate computer application functions provided in the enhancement package immediately, while an accounting department of the entity may delay activation of accounting functionality until a later date, e.g., after the end of the fiscal year. The information technology (IT) administrator, for example, can perform the activation steps for the particular department.
Enhancement packages are provided to a customer, such as a manufacturing entity or services entity. A group of data structures identifying the functions and computer objects that provide the functions are typically delivered with the computer code. The computer code and the group of data structures may be installed on the entity's computer system. A portion of the data structures may arrange in a hierarchical fashion the numerous functions that are part of the computer application enhancement. The hierarchy may be configured in the commonly known trunk, branch, node, and leaf structure. Below the nodes in the hierarchy may be computer objects, shown as leaves in the data structure, that are responsible for the implementation of a particular function. This particular data structure may be called an implementation guide. A purpose of the implementation guide is to allow easy indication of the enhancement package implementation by a user, such as an IT administrator, of the computer application functions that have been changed. In order to maintain computer application configuration management integrity as enhancement packages are introduced, changes to the implementation guide should reflect only changes to a computer application function.
The hierarchy may be used by computer system administrators to implement the enhanced functionality resulting from the enhancement changes in the computer objects. The hierarchy, when presented in a graphical user interface, allows a user to see which computer objects are affected by the selection of a particular node or leaf within the hierarchy. For example, when a department of an entity may want to implement a new computer application function provided with the installed enhancement package, a function specific to the particular department may be selected.
FIG. 1 illustrates a graphical representation of the operation of a tool for facilitating use of the implementation guide for selection of a computer function. In FIG. 1, a tool 100 presents in a graphical user interface a list of functions 110 included in the latest enhancement package and any functions that have been installed to the computer system. The user may select a function to be implemented by selecting the function in a graphical user interface by, for example, selecting a check box with an input device (e.g., mouse or keyboard) that sets an indication (e.g., inserts a checkmark) when selected by the user. As the selections are made, the graphical user interface will cause switches 1, 3 and 5 in a switch framework 120 to be activated. The selected functions may represent nodes, e.g., specific computer function XYZ, or enterprise computer function ABC, and/or specific leaves, e.g., management or recruiting. Note that more than one node, and more than one leaf may be selected. The activated switches 1, 3 and 5 may allow for implementation of the associated computer objects 150, 152, 154, 156, 158 and 160 in the list of computer objects 150 that implement the selected functions.
However, given the complex nature of an enterprise-wide computer application, the selection of particular nodes or leaves may cause conflicts with other nodes or leaves. For example, a selection of a computer object on one node may call for a software module that performs an operation that is an opposite operation performed by another computer object that has been selected by the user. In this case, the two computer objects are said to “conflict.” The tool 100 may present to the user both functions even though the switches conflict.
For example, FIG. 2 illustrates a table for explaining the problem resulting from conflicting computer objects. Structure nodes (e.g. NODE 1 and NODE 2) and activities may be assigned to software switches e.g., S1 and S2, that include settings that can define how the nodes/activities may react depending upon the state (e.g., on or off separately, or both on or off simultaneously) the switches S1 and S2 are in after a particular selection. It may be possible to assign more than one switch to the same implementation guide node/activity. When two or more switches are assigned to the same implementation guide node/activity, the probability of the possible reactions to the switch state causing a conflict increases. A data structure accessible by a processor may be maintained in a data storage that tracks the assignment of particular function switches to nodes or sub-nodes and vice versa. In FIG. 2, the different combination of settings for each switch and resulting reactions at the respective nodes are shown in rows 210-240. In the illustrated example, possible reactions are ‘hide’ and ‘show’, which means the node/activity associated with the particular switch may, respectively, either be hidden (hide) from view in the user interface, or visible (show) on the user interface based on the switch setting. For example, in row 210, the switches S1 and S2 are both in a switched OFF state, and the assigned nodes NODE 1 and NODE 2, respectively, are both “HIDDEN.” Rows 220 and 230 show the reactions related to the respective nodes, NODE 1 and NODE 2, when switch S1 is on and switch S2 is off, and when switch S2 is off and switch S2 is on. Switches with the reaction “VISIBLE” (i.e., show) override all switches that have the reaction “hide.” In other words, one switch may cause a node to be visible and the other may cause a node to be hidden. In that case, the switch with the reaction to “show” will override the switch with the reaction to “hide.” In more detail, consider the situation shown in FIG. 2:
Structure nodes NODE1 and NODE2 are sibling nodes within an implementation guide hierarchy because in the enhancement package, NODE2 is semantically a full replacement of NODE1. When the enhancements in the enhancement package are implemented, NODE2 is intended to replace NODE1.
Structure node NODE1 is assigned to switch S1 with reaction ‘show’ when switch S1 is switched on, and a reaction ‘hide’ when switch S1 is off. This means NODE1 should be hidden when switch S2 is switched on (reaction ‘hide’ for NODE1) because switch S2 displays the new replacement structure node NODE2.
But as mentioned above, a problem is that it is not possible to hide NODE1 with switch S2 when S1 is switched on. This is because reaction ‘show’ has been predetermined in the system to “win” over the reaction ‘hide’.
As a result, both nodes NODE1 and NODE2 are presented (i.e., visible) to a user in the graphical user interface. The problem of conflicting computer objects in the implementation guide are typically resolved by the developers before a customer ever has the opportunity to make a conflicting selection. The developers typically implement a work around in the implementation guide to resolve the conflicts by assigning additional nodes.
To resolve the conflict, a developer may configure a “work around” to the implementation guide. For example, the developer may create a new node, say NODE3, in the implementation guide structure to address conflicting computer objects. The new node, say NODE3, may be assigned to switch S2 with a reaction to hide when switch S2 is on, and may also be the parent node of NODE1. NODE2 is also assigned to switch S2 with a reaction to show. By NODE3 being the parent of NODE1, this takes advantage of the rule that all children of a node take the same reaction as the parent. So if NODE3 is given the reaction to hide when switch S2 is on, NODE1 will also be hidden. When switch S2 is selected to be on, NODE2 is visible and presented in the graphical user interface, and NODE3 and its child, NODE1, are hidden.
The additional node (NODE3), without corresponding additional functions, can make the hierarchy of the implementation guide confusing because the additional node only addresses a specific conflict between two nodes. The confusion may be compounded by future enhancements that add further nodes that merely address node conflicts to the computer application. In addition, the configuration management protocols for the implementation guide may be compromised because changes to the implementation guide do not reflect only changes to a computer application function, but also include the switch workarounds.
An example shown in FIG. 2A illustrates a scenario in which a switch is activated and a computer function is presented in a screenshot 200A of a graphical user interface. A graphical user interface presents to a user the screenshot 200A displaying in a hierarchy the implementation guide (IMG) for an exemplary enhancement package. Elements 272 and 274 graphically represent nodes in a hierarchical data structure at which the particular nodes “User Interface Settings” and “Work Settings” may be located. Also present in the data structure may be the switches that turn “on” or activate the particular computer functions indicated by the respective nodes. In the illustrated example, the switch 276 labeled “SS1” may be a switch that activates the particular computer functions represented by nodes “User Interface Settings” and “Work Settings.” Depending upon the reaction (“show” or “hide”) assigned to the particular state of switch 276 name “SS1”, either node “User Interface Settings” 272 and “Work Settings” 274 may be presented in the graphical user interface 200A.
An example of a workaround as presented in a screenshot 200B of a graphical user interface is shown in FIG. 2B. The node “User Interface Settings” 284 may be, in the illustrated example, semantically replaced with the new functions at node “Settings for User Interface and Process” 286. In the workaround screenshot 200B, the nodes “Process for Global Employee Management” 280, “User Interface Settings” 284 and “Work Settings” 288 are assigned to switch SS1 287, while the workaround “User Interface Settings—General” 282 and semantic replacement “Settings for User Interface and Process” 286 nodes are assigned to switch SS2 289. In the illustrated example, the “Settings for User Interface and Process” 286 computer function may be a semantic replacement for the “User Interface Settings” 284 computer function. In this case, the present example illustrates the state of the implementation guide (IMG) when switch SS1 (element 287) is “on” and switch SS2 (element 289) is “off.” The workaround inserts the node 282 entitled “User Interface Settings—General” in the hierarchy as a node above the “User Interface Settings” node 284. The node 282 (and implicitly node 284 which is a sub-node to node 282) may have the reaction “hide” assigned to it, and node 286 has the reaction “show” when the switch SS2 289 is switched “on.”
FIG. 2C illustrates the effect of the workaround on the graphical user interface that displays the implementation guide to the user. In the screenshot 200C, when the state of the switches 287 and 289 are both switched to “on” respectively, the workaround may be effective (i.e., the semantic replacement “Settings for User Interface and Process” replaces “User Interface Settings”, and the nodes 282 and 284 may be hidden. The user will be presented with a view as shown in FIG. 2C that presents nodes 280, 286 and 288 with the indication of the respective switches 287 and 289.
As can be seen in FIG. 2B, the “workaround” solution creates an additional node, e.g., 282, which based on its name, “User Interface Settings—General” is not very descriptive of the nodes true purpose. Furthermore, if and when additional nodes are required, other names must be given to those nodes further cluttering the implementation guide and masking the purpose of the presented nodes.
Accordingly, the inventors have recognized the need for a tool that presents the implementation guide in a format absent of additional “work around” nodes that addresses the conflicting computer objects and satisfies the configuration management protocols of the implementation guide.